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Summary  of  Activities 

Through  sponsorship  of  the  US  Army  Research  Office,  the  University  of  Southern  California 
Information  Sciences  Institute  hosted  a  1-day  working  meeting  on  the  topic  of  Design  for 
Security,  July  23,  2014  at  the  Marina  del  Rey,  CA  location.  While  the  primary  focus  was  on 
electronics  (ASICs,  FPGAs,  COTS,  etc),  some  discussion  of  techniques  at  other  system  levels 
was  also  mentioned,  especially  in  the  invited  talks.  In  the  past  decade,  more  and  more  fabrication 
of  advanced  ICs  has  migrated  offshore,  largely  because  of  global  economic  pressures. 

Fabrication  facilities  dedicated  to  supporting  the  Department  of  Defense  can  no  longer  provide 
the  performance,  variety,  and  volume  of  ICs  at  the  cost  needed.  Such  trends  have  raised  concerns 
regarding  the  reliance  of  U.S.  defense  systems  on  high-performance  ICs  and  the  potential 
vulnerabilities  of  these  systems  if  fabricated  and/or  developed  offshore.  While  previous 
programs,  such  as  DARPA’s  Trust  in  Integrated  Circuits  and  Integrity  and  Reliability  in 
Integrated  Circuits,  sought  to  address  these  concerns  through  hardware  and  design  validation,  the 
design  perspective  to  explore  what  can  be  done  during  the  design  phase  to  increase  the  security 
of  a  system  has  not  received  equal  attention.  This  workshop  addressed/discussed  how  to 
incorporate  security  as  a  first-rate  metric  during  the  design  flow,  much  like  performance,  area, 
and  power.  Some  of  the  topics  discussed  include: 

•  Vulnerabilities  in  the  current  design  flow  of  integrated  circuits  and  embedded  systems 

•  Potential  holistic  solutions  to  building  in  security  during  design 

•  Metrics  for  measuring  security 

•  Defining  the  trade-off  space  between  security  and  other  design  constraints  such  as  cost, 
power,  and  reliability 

•  Defining  the  levels  in  the  design  flow  where  it  makes  sense  to  model  threats  and  define 
appropriate  defenses  in  response 

•  Security  as  it  relates  to  3rd-party  IP  and  FPGAs 

•  Implications  on  test  procedures 

A  wiki  for  distribution  of  workshop  presentations,  findings,  and  even  videos  was  set  up  at 
https://uscisi.atlassian.net/wiki/display/DFSWM.  Attendees  and  other  approved  users  were  given 
accounts  for  access  to  this  material,  and  much  of  the  material  in  this  final  report  is  taken  directly 
from  the  postings. 

Detailed  Activities 

The  agenda  for  the  workshop  can  be  found  in  Appendix  A.  The  day  was  organized  into  a 
number  of  invited  talks,  a  panel  session  for  questions  and  answers  with  the  invited  speakers  as 
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well  as  to  identify  the  main  topics  to  be  addressed  during  breakout  sessions,  and  then  two 
breakout  sessions.  The  invited  speakers  and  talk  titles  are  given  below: 

•  Security  in  Mobile  Systems  -  Rob  Aitken,  ARM 

•  Zynq  Security  Components  and  Capabilities  -  Steve  Trimberger,  Xilinx 

•  EDA  Perspective  on  Tools  for  Hardware  Trojan  Detection  and  Supply  Chain  Security  - 
Serge  Leef,  Mentor 

•  STARSS:  Fundamental  Design  for  Security  Research  Jointly  Funded  by  Industry  and 
Government  -  Celia  Merzbacher,  SRC 

These  presentations  can  be  found  in  Appendix  B.  Following  the  invited  presentations  and  panel 
session,  the  attendees  self-organized  into  roughly  equally-sized  groups  between  two  breakout 
sessions:  one  to  address  theory/metrics,  and  the  other  to  address  issues  envisioned  for  reduction 
to  practice.  Some  of  the  issues  related  to  these  themes  and  presented  to  attendees  were: 

•  Theory/Metrics: 

—  Potential  holistic  solutions  to  building  in  security  during  design 
—  Metrics  for  measuring  security  given  known  vulnerabilities  in  current  design 
flow 

■  How  can  metrics  be  defined  so  that  security  can  be  incorporated  in  design 
flow  as  constraint  analogous  to  speed,  area,  power 

•  Practice: 

—  Defining  the  trade-off  space  between  security  and  other  design  constraints  such 
as  cost,  power,  and  reliability 

—  Defining  the  levels  in  the  design  flow  where  it  makes  sense  to  model  threats  and 
define  appropriate  defenses  in  response 
—  Security  as  it  relates  to  3rd-party  IP  and  FPGAs 
—  Implications  on  test  procedures 

Attendees  were  then  given  the  following  charge  for  their  respective  breakout  sessions: 

•  Establish  a  research  agenda  that  will  solve  the  problem 

—  Identify  key  aspects  of  the  problem  and  a  research  plan  for  solving  the  problem 

■  Identify  key  aspects  of  the  problem  that  need  investment 
—  Identify  key  questions  to  be  answered  and  a  process  for  answering 

—  Identify  five  central  challenges  that  are  worthy  of  pursuing  and  need  investment 

The  findings  of  the  breakout  sessions  are  best  summarized  by  the  top  5  research  area  priorities 
identified  as  needing  investment: 

•  Methods  to  create  verifiably  secure,  attack-resistant  IP  at  all  levels  of  design  hierarchy, 
including  definitions  of  metrics 

•  Methodologies/techniques  for  the  behavioral  modeling  of  the  security  of  devices  and 
systems 

•  Tools  for  secure  interplay  between  hardware  and  software 

•  Design  environment  for  modeling  and  simulating  hardware  attacks  and  actions  for 
mitigation 

•  Extensions  to  HW  description  languages  that  capture  security  attributes 
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An  outbrief  presentation  summarizing  the  motivation,  issues,  and  findings  of  the  workshop  can 
be  found  in  Appendix  C.  The  list  of  workshop  attendees  along  with  their  affiliations  is  given  in 
Appendix  D.  The  workshop  attendance  ended  up  being  34  with  a  mix  of  commercial  industry, 
defense  industry,  academia,  and  government  agency  participants. 
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Appendix  A  -  Design  for  Security  Workshop  Agenda 


Design  for  Security  Working  Meeting  Agenda 

University  of  Southern  California 
Information  Sciences  Institute 
Marina  del  Rey,  CA 
July  23,2014 


Time 

Topic 

Presenter(s) 

Room(s) 

08:30 

Sign  in  /  Continental  breakfast 

1137 

08:45 

Welcome/Logistics/Intro/Expectations 

Jeff  Draper,  USC  ISI 

1135 

09:00 

Security  in  Mobile  Systems 

Rob  Aitken,  ARM 

1135 

09:20 

Zynq  Security  Components  and  Capabilities 

Steve  Trimberger, 
Xilinx 

1135 

09:40 

EDA  Perspective  on  Tools  for  Hardware  Trojan 
Detection  and  Supply  Chain  Security 

Serge  Leef,  Mentor 

1135 

10:00 

STARSS:  Fundamental  Design  for  Security 
Research  Jointly  Funded  by  Industry  and 
Government 

Celia  Merzbacher, 
SRC 

1135 

10:20 

Break 

10:30 

Panel  -  Q&A  from  invited  talks  /  Q&A  for 
setting  up  breakout  sessions 

Aitken,  Trimberger, 
Leef,  Merzbacher, 
Wang,  Fazzari,  Draper 

1135 

11:30 

Lunch 

1135 

12:20 

Report  to  breakout  sessions 

12:30 

Breakout  Session  1  -  Metrics 
Room  1135 

Metrics  for  measuring  security 
given  known  vulnerabilities  in 
current  design  flow;  how  can 
security  be  incorporated  in  design 
flow  as  constraint  analogous  to 
speed,  area,  power 

Breakout  Session  2  -  Practice 
Room  689 

Security  as  it  relates  to  IP/FPGA; 
impact  on  design  flow  including 
test  procedures 

1135,689 

14:30 

Initial  report  out 

Breakout  Session 
Leaders 

1135 

15:00 

Break  /  report  back  to  breakout  sessions 

15:15 

Breakout  Session  1  -  Metrics 
Room  1 135 

Follow-up  session  to  address 
feedback  from  initial  report  out  and 
finalize  report 

Breakout  Session  2  -  Practice 
Room  689 

Follow-up  session  to  address 
feedback  from  initial  report  out  and 
finalize  report 

1135,689 

16:15 

Final  report  out 

Breakout  Session 
Leaders 

1135 

17:15 

Concluding  remarks  /  Plan  for  report 

Draper,  Wang,  Fazzari 

1135 

17:45 

Adjourn 

18:30 

Dinner  (stay  tuned  for  more  details) 

Appendix  B  -  Invited  Presentations 


Mobile  Security  Systems 


Rob  Aitken 
ARM  Fellow 
July  23  2014 


The  Architecture  for  the  Digital  World® 


About  ARM... 


SIM 


>  50  Billion  ARM  chips 
(>10B  /year) 

>  ~  $1 .2B  Revenue/year 

>  ~3000  Employees 

>  >95%  Smartphone 

&  Tablet  market  share  „  „ ,  . . 

Cellular  Modem 


ARMTRUSTZONE 

System  Security 


WiFi 


GPS 


Bluetooth 
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Apps  Processor 


Camera 


Sensor 

Hub 


Power  Mgmt 


Flash  Controller 


Touchscreen 


ARM 


The  Mobile  Threat  Environment 


■  Increasing  risks 

■  Social  engineering -Trojans, 
phishing,  APT 

■  Malware 

■  Physical  loss  or  theft  leading  to 
risk  to  data  -  calendar, 

Phonebook  and  email 

■  Improperly  secured  devices  -  no 
PIN  lock 

■  User  intervention -jailbreaking, 
unlocking 

■  Mobile  has  become  the  enterprise 
security  boundary 

■  Need  to  design  in  the  right 
system-wide  security  (not  just 
more  security) 
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ARM 


Whose  Data  Is  Involved? 


■  User 

■  Personal  information,  contacts,  location,  photos,  etc. 

■  Carrier 

■  Network  interface 

■  Enterprise(s)? 

■  BYOD 

■  Apps 

■  Content  providers 

■  DRM  for  movies,  songs,  etc. 

■  Finance  companies 

■  Account  data,  passwords 

■  IOT 

■  home  automation,  health,  etc. 
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ARM 


Security  Profiles 


SmartCards  /  HSMs 


Cost/Effort 
To  Attack 

▲ 


/" 


"\ 


TrustZone  based  TEE 


"N 


Invasive  HW  Attacks 

•  Well  resourced  and  funded 

•  Unlimited  time,  money  & 
equipment. 


Software  Attacks 

•  Malware  &  Viruses 

•  Social  engineering 


Non-invasive  HW  Attacks 

Side  channels  (DEMA,  DPA) 
Physical  access  to  device  - 
JTAG,  Bus  Probing,  10  Pins,  etc. 


^  Cost/Effort 
w  to  Secure 
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ARM 


Mobile  Solution  Is  Not  PC  Solution 


■  PC  era  security 

■  Add  layers  of  software  security  (SSO  etc.) 

■  Add  hardware  security  (CVC,  key  fobs,  etc.) 

■Too  unwieldy  and  confusing  for  mobile  environment 
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ARM 


Mobile  Security  Approach 


■  Hypervisor  (with  hardware  support) 
separating  large  pieces  of  code 

■  Small,  certifiable  Trusted  Execution 
Environment  inside  Application 
processor  isolated  using  ARM 
TrustZone  technology  protecting 
against  software  attacks 

■  Secure  Element  for  tamper  proof 
security 


7 


Design  For  Security  Workshop,  July  23  2014 


ARM 


Trusted  Execution  Environment 


■  Hardware  root  of  trust 

■  A  basis  for  system 
integrity 

■  Integrity  through 
Trusted  Boot 

■  Secure  peripheral 
access 

■  Screen,  keypad  , 
fingerprint  sensor  etc. 

■  Secure  application 
execution 

■  Trust  established 
outwards 

■  With  normal  world 
apps 

■  With  internet/cloud 
apps 


id. 


Rich  OS  Application  Environment 

r-  e 
% 

i 

Client  Applications 

n  'VEO 


Trusted  Execution  Environment 


Trusted 
Application 
DRM 


Trusted 

Application 

Corporate 


TEE  Functional  API 


GlobalPlatform  TEE  Client  API 


GlobalPlatformTEE  Internal  API 


Trusted  Core 
Environment 


TEE  Kernel 


Hardware  Platform 


Resources 


w  \ 

HW  Keys,  Secure  Storage, 
HW  Secure  Trusted  Ul  (Keypad,  Screen). 

Crypto  accelerators. 

NFC  controller. 

Secure  Element,  etc. 
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ARM 


Castle  Analogy 


■  Layers  of  defense 

■  Reducing  attack  surface 

■  Increasing  isolation 

■  Principle  of  least  privilege 

■  Most  precious  assets 
protected  by  multiple  layers  of 
security 


h 
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User  Apps 
&  Malware 


ISNFR 

WARD 


OUTER 


H  \Rl  I 


INNERMOST 
WARD  I 


ARM 


Castle  Analogy 


But... 

■  Modem  OS/Framework  is  ~1 0GB  + 
GBs  of  Apps 

■  So  maybe  we  should  think  of  a 
walled  city  &  castle 

■  Attacks  happen 

■  Everyone  knows  what  the  assets 
are  and  which  room  they  are  in 

■  Where  to  put  high  value  assets 
such  as  keys? 


Cripplegate 


bshopsgate 


Moorgate 


Aldersgate 


Royal  Exchange 

PQ 


Postern 

gate 


Crown  Jewels 


Smithfield 

Newgate 

i 

Ludgate  I 

r 


Cheapside 

St.  Paul's  Cathedral 


ivioorrieias 


Pudding  Lane 


River  Thames 


: London 
Bridge 


ToM,erofLond( 


on 


Thief  entered  here 
&  stole  keys! 


Implementation  details  matter! 
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Castle  Analogy  with  TrustZone  Based  TEE 


10-20  GB 

INNERMOST 

ivardI 


■  TrustZone  based  TEE  creates  a  second 
(much  smaller  security  boundary)  castle 
with  only  one  door,  carefully  designed 
entry/exit  &  APIs 

■  Keys  only  used  in  Secure  World, 
Protected  Crypto, 

Encrypted  storage 
Secure  execution 
Secure  peripherals 

■  Offers: 

Integrity  (part  of  Trusted  boot) 
Confidentiality 

■  TrustZone  TEE  Castle  is 
invisible  to  normal  world 


1-2MB 
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ARM 


Castle  Analogy  with  TrustZone  Based  TEE 

Secure  World 


Isolated  Trusted  Apps 


Global  Platform  Client  API 
SMC  calls 

e.g.  ARM  Trusted  Firmware 


INNERMOST 
WARD  I 


uesign  ror  oecuniy  vvorKsnop,  juiy  zo  zu  14 


ARM 


Trusted  OS 

e.g.  Trustonic  t-base300 


1-2MB 


Normal  World 


Ml 


OUTER 

WARD 


TrustZone:  Two  CPUs  virtualized  in  one 


Rigid  Boundary 


■  In  pre-TrustZone 
Systems: 

■  Rigid  allocation  of  MHz / 
resources  independent  of 
the  application. 

■  Silicon  costs  with 
redundant  hardware  that 
is  idle  most  of  the  time 

■  Complex  control  logic  and 
deficient  performance  and 
power  consumption 


nnnnnnrnnnnnni 
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E 

S 
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C 
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G 
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I 


CPU  for 

Normal  OS  code 


CPU  for 

Trusted  code  only 
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Secure 

domain 
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ARM 


nnnonnnnnnnn 


TrustZone  Basics 


Key  advantages  over  separate 

secure  processor  solutions: 

■  CPU  MHz/resources  are 
dynamically  shared  according  to 
demands 

■  The  two  isolated  domains  are 
implemented  in  the  same 
machine  with  no  duplication  of 
HW 

■  Difficult  to  give  precise 
“overhead”  values  since 
secure  and  non-secure 
tightly  integrated  from 
design  standpoint 

■  Simpler  and  more  flexible 
platform  designs,  lower  costs 
and  high  power/performance 
efficiency 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

1= 

c 

c 

c 

c 

c 
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VI 
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Non  lecuru 

i 

Stcurt 

privileged 

pnvilaqtd 

~T 

K' 

Non  secure 

Secure 

User 

User 

Non-secure 

domain 


TrustZone  Archltecure  Extensions 


TrustZone  awareness  present  in  AXI  bus 


[TrustZone  System  level  Components  | 


□□□□□□□□□□□□□uuuuu 
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ARM 


Attacking  the  TEE  -  Man  In  The  Middle 


Can  then 
access 
memory  used 
to 

communicate 
between 
Client  App 
and  Trusted 
App 

Malicious 
App  can 
intercept 
traffic, 
replace  it, 
modify  it  or 
eavesdrop 
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Side-Channel  Attacks 


r 


Rich  OS 


Client  App 


Malicious 

App 


Trusted 

Execution 

Environment 


Trusted 

App 


Trusted 

App 


Kernel 


Secure  call  to  TEE  -e®  Monitor 


J 
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ARM 


Defenses 


■  Normal  World  to  Secure 
World  communications 
are  always  exposed  and 
vulnerable 

■  Mitigation 

■  Don’t  design  systems  that 
rely  on  secure 
communications  between 
Normal  World  and  Secure 
World 

■  Always  use  trustworthy 
components  -  crypto 
library,  TEE  and 
protocols 


Malicious  App 
can  intercept 
traffic,  replace  it, 
modify  it  or 
eavesdrop 


3d 

ation 

Environment 


Secure  call  to  TEE 


Trusted 

App 

Trusted 

App 

7> 

l 

t|  ! 

(ernel 
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Propagating  System  Security 


Bus  Slaves 
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TrustZone  Controllers  -  Vital  Statistics 


Code 

Product 

Main  Function 

Key  Features 

Size 

TZC-380 

TrustZone 

Address 

Space 

Controller 

Partition 
external  DRAM 
into  secure  and 

non-secure 

regions 

Configurable  up  to  16  regions  of  size 
32K  to  4G,  each  with  8  sub-regions 
(down  to  4K). 

Configurable  registering  to  meet  timing 
constraints  with  minimum  latency. 

AXI  interface  for  compatibility  with  NIC- 
301  and  DMC-34x. 

10-100k 

gates 

BP141 

TrustZone 

Internal 

Memory 

Wrapper 

Protects 
internal  SRAM 

Manages  a  single  secure  region  within 
the  SRAM. 

AXI  interface. 

<1k 

gates 

BP147 

TrustZone 

Protection 

Controller 

Prevents  non- 

secure 

accesses  to 
peripherals 

Allows  peripherals  to  be  safely  shared 
by  the  Secure  and  Non-Secure  worlds. 
APB  interface. 

<1k 

gates 
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Application  of  Hypervisor  for  BYOD 

Two  Personas 

■  Mutual  Distrust  model 
between  OSs 

■  Ensuring  Enterprise  OS 
Security,  while  protecting 
Consumer  OS  Privacy. 

■  Enabling  Enterprises  to 
have  control  of  their  own 
assets  in  case  of  loss 
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Secure  Content  Path:  SoC  Requirements 


Firmware 
protected  against 
tampering 


Any  SW  component  directly 
used  in  setting  up  protected 
memory  path 


Decoders,  mixers,  Tenderers, 
DRM 


Critical  components  placed  in 
secure  processing  space 


Integrity  checked  at  boot  time 


Unencrypted 
content  protected 


After  DRM  protection  removed 


Unencrypted  content  never 
accessible  to  processes 
running  in  HLOS 


Unencrypted  content  only  ever 
written  to  protected  memory 


Memory  buffers 
protected  by  HW 
control 


All  memory  used  in  processing, 
decoding,  mixing  and  rendering 


Sufficient  memory  for  video 
bitstream  and  frame  buffer 


Not  accessible  by  HLOS  or 
unauthorised  HW  or  SW 


Output  only  to  internal  display 
or  via  protected  export  clients 
such  as  HDCP  and  DTCP 
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ARM 


Secure  Implementation  Example 


Normal  World 


Secure  World  (TEE) 


Video  Player 


DRM  Client 


Video  Trusted  App 


DRM  Trusted  App 


Secure  OS  in  TEE 


Secure  Monitor/Boot 


ARM  CPU  with  TrustZone 
Extensions 


Mali-V500 


Mali  Display  & 
Composition 


Rich  OS  Memory 


Trusted  "Protected"  Memory 


Low  cost  and  complexity 

v _ - _ ) 

•  Secure  CPU,  bus  fabric  and  Video  from 
a  single  source 

•  System  IP  designed  to  work  together 

•  Simple  SW  integration  -  create  a  secure 
session  then  manage 
scheduling/control  as  normal 

/  \ 

Minimal  memory  fragmentation 

^ _ ) 

•  Major  issue  for  HD  content 

•  Video  MMU  can  be  used  for  secure 
sessions  by  TEE 

•  No  need  to  assign  large,  contiguous 
secure  buffers 


/ - \ 

Increased  flexibility  and  protection 

v _ - _ ! _ / 

•  Simultaneous  protected  and  un¬ 
protected  video  streams 

•  Additional  protection  of  video  firmware 
(read-only)  and  data  (non-executable) 
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f:  XI  LI  NX 

ALL  PROGRAMMABLE™ 


Zynq  Security  Components  and 
Capabilities 


Steve  Trimberger,  Xilinx 


©  Copyright  2014  Xilinx 


Agenda 

>Security  Features 
Inherited  from  FPGAs 

>Zynq  Secure  Boot 

>TrustZone  Integration 


2 

©Copyright  2014  Xilinx  C  XILINX  >  ALL  PROGRAMMABLE,. 


Zynq  All-Programmable  SoC 

>  Processor  System  (PS) 

-  2x  ARM9  866MHz-1GHz  32K/32K 
I/D  Caches 

-  512KB  shared  L2  Cache 

-  256KB  On-chip  memory 

-  Memory  controller 

-  Bus  interfaces,  timers 

-  Libraries,  OSs,  middleware 

>  Programmable  Logic  (PL) 

-  28K  -  440K  LCs 

-  240K-3MB  RAM 

-  80  -  2020  DSP  blocks 

-  I/O,  Transceivers,  PCIe,  Ethernet... 

>  Programmable  ADC 

-  Inputs  from  Voltage,  Temp  sensors 


C  XILINX  >  ALL  PROGRAMMABLE, 


>  AMBA  AXI  bus  fabric 


©  Copyright  2014  Xilinx 


Agenda 

>Security  Features 
Inherited  from  FPGAs 

>Zynq  Secure  Boot 

>  rustZone  Integration 
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Passive  Security  Features:  Device  Identification 


>  Device  DNA  and  User  eFUSE  field 

-Uniquely  identify  the  chip 

-An  application  can  be  tied  to  exactly  that  chip  and  no  other 


> User eFUSE  bits  disable  unencrypted 
bitstreams 

-FPGA  rejects  unencrypted  bitstreams 

-Restrict  system  usage  to  authorized  applications  only 


Page  5 
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II  XILINX  >  ALL  PROGRAMMABLE.. 


Active  Security  Features:  Monitors 

>  DETECT  if  there  is  activity  on  JTAG 
chain  and  DISABLE  the  JTAG  chain 

-JTAG  is  arguably  the  #1  vulnerability  in  every 
integrated  circuit. 


TMS 

CD - 

TCK 

CD — T 


TDI 

CD 


TMS 

TCK 

DEVICE  1 

TDI 

TDO 

>ADC  can  monitor  user-specified 
temperature  and  voltage  limit 


>SEU  checker:  detects  and  repairs 
configuration  bit  flips.  Detects 
attempts  to  subvert  operation  with 
focused  radiation 


TDO 

CD 
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II  XILINX  >  ALL  PROGRAMMABLE.. 


Active  Security  Features:  Actors 

>  Clear  the  design,  data  and  key  from  inside  the 
FPGA  

»GTS  macros  immediately  tri -state  pins 


>PROG_B  intercept:  user  application  prevents 
reconfiguration  until  cleanup  done 
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II  XILINX  >  ALL  PROGRAMMABLE. 


Agenda 

> Security  Features 
Inherited  from  FPGAs 

>Zynq  Secure  Boot 

>  rustZone  Integration 
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Dual  Authentication  in  Zynq  Devices 

>  Symmetric  (AES-HMAC) 

-High-speed  for  fast  configuration 
-Inherited  from  FPGA 

> Asymmetric  (RSA) 

-Provides  authentication  without  using  secret  data 
-Key  in  silicon  is  “public”  -  does  not  have  to  be  secret 
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II  XILINX  >  ALL  PROGRAMMABLE.. 


Zynq  Key  Loading 


I 


Vivado/ISE 


READY  TO 
BOOT! 


"I 

i~T* 

I 

I 

I 


Public  Key 
(eFuse) 


I 

II 

|1 

8 11  I  11 

lltr 


Secret 

“Red”  AES  Key 
BBRAM  or  eFuse 


Programmable  Logic 
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External  NV  Memory 


Load:  1 

CT  RSA  Ve  Ay: 

FSBL  1 

k  - 

Ls  : 

Deorvnf : 


Decrypt: 
PL  Image 


Processing  System  (PS) 


BankO 

MIO 

(15:0) 


I/O 

MUX 

(MIO) 


Bankl 

MIO 

(53:16) 


Input  Clock 
&  hreq 


I/O  Peripherals 


SPIO 

SPI  1 

I2C  0 

I2C  1 

CAN  0 

CAN  1 

UARTO 

UART  1 

GPIO 

SDO 

SD  1 

USB  0 

USB  1 

ENETO 

ENET  1 

General 

Settings 


Reset 


Application  Processor  Unit  (APU) 


SWDT 


TTC 


NEON /FPU  Engine 


System 

Level 

Control 

Regs 


MMU 

Cortex  -A9 
MPCore  CPU 

32  KB 
1-Cache 

32  KB 
D-Cache 

NEON /FPU  Engine 


MMU 

Cortex  -A9 
MPCore  CPU 

32  KB 
1-Cache 

32  KB 
D-Cache 

GIC 


Snoop  Control  Unit 


-► 


-► 


Central 

Interconnect 


FLASH 

Memory 


SRAM/NOR 


Quad  SPI 


▼ 


Clock 

Generation 


Extended  MIO 
(EMIO) 


° 

1 

2 

CO 

A  A 


DMA  8 
Channel 


A 


CoreSight 

Components 


I 


DAP 


DevC 


PS  to  PL 
Clock  Ports 


GTX 

12.5  Gbps 


32b  GP 
AXI 
Master 
Ports 


DMA  Sync 


0  1 


2  3 


512  KB  L2  Cache  &  Controller 


OCM 

Interconnect 


Boot  ROM 


Programmable 
Logic  to  Memory 
Interconnect 


32b  GP 
AXI 
Slave 
Ports 


DMA 

Channels  Config 
AES/SHA 


IRQ 


Memory  Interfaces 


High  Performance 
AXI  32b  /  64b  Slave 
Ports 


XADC 


AMBA  Connection  Legend 

Arrow  direction  shows  control,  Data  flows  in  both  directions 

Configurable  AXI3  32  bit  /  64  bit 
AXIS  64  Bit  /  AXI3  32  bit  /  AHB  32  bit  / 


Programmable  Logic(PL) 


PCIE 

Gen2 


64  b 
AXI 
ACP 
Slave 
Port 


Select 
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Zynq  Secure  Boot 


>  Trust  starts  with  boot  ROM 

>  In  secure  boot,  FSBL  is 
authenticated  before  execution 

-  RSA-2048,  user  chooses  the  key 

>  FSBL  is  just  (authenticated)  code. 
It  can  do  anything  securely 

-  Partition  into  pieces  to  fit  into  OCM 

-  RSA  authentication  for  each  partition 

-  AES-HMAC  for  each  partition 

-  New  authentication  or  decryption 
algorithms 

-  Key  rolling 

>  Single-entity  model 

-All  secure  boot  starts  with  PS  boot 

-  Secured  PS  boot  manages  PL  boot 


II  XIUNX  >  ALL  PROGRAMMABLE.. 
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Agenda 

> Security  Features 
Inherited  from  FPGAs 

>Zynq  Secure  Boot 

>TrustZone  Integration 
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TrustZone 


>  ARM  TrustZone:  separates  Secure  World  processes  and 
components  from  Normal  World 

>  Secure  World  may  access  all  components.  Normal  World  may 
not  access  secure  world  components. 


>  Trust  tags  added  to  AXI  bus  transactions:  AWPROT,  ARPROT 

>  Mapping  of  components  to  Secure  World  is  done  in  the  PS 


Full  SoC  HW  Accessible  to  "Secure  HW  Accessible  to  "Normal 

(All  HW)  World"  software  World"  software 

(All  HW)  (HW  subset) 

©Copyright  2014  Xilinx  C  XILINX  >  ALL  PROGRAMMABLE. 


TrustZone  in  Programmable  Logic 


>  AXI  Switches  handle  TrustZone 
protection  bits 

>  TrustZone  pushed  to  AXI  bus 
endpoints  in  PL 

-These  are  firmware,  built  from 
FPGA  fabric 

-  They  operate  just  like  the 
corresponding  hard  logic  in  PS 

-They  are  marked  by  the  user  at 
compile  time  as  Secure  World  or 
Normal  World 

-  Check  ARPROT,  AWPROT  during 
operation 
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What  Does  This  Mean? 


>  Chain  of  Trust  lets  you  build  what  you  want  in  code  and  fabric 

>  Control:  JTAG,  configuration 

>  Monitoring 

>  Defensive  Actions 

>  Algorithm  choice 

>  DPA  resistance 

>  HW/SW,  it’s  all  good 

http://www.xilinx.com/applications/securitv/index.htm 

http://www.xilinx.com/products/silicon-devices/soc/zynq-7000/securitv.html 
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II  XILINX  >  ALL  PROGRAMMABLE.. 


EDA  Perspective  on 
Hardware  Cybersecurity 


Serge  Leef 


Vice  President  and  General  Manager 

New  Ventures 

System  Level  Engineering  Division 


—Menior 

Graphics9 


Cybersecurity  I  s  A  'Big'  Topic 
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I  nternet  of  Things  Dramatically  Expands  the 
Threats  to  Cyber  Security 


ATTACK  TYPES 


RELATIVE  IMPACT 


loT 


100  Billion 


Source:  “Understanding  I  integrated  circuit  Security  Threats  System  Design  and  Management,  Asif  Iqbal  2011 
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Embedded  Threats  Moving  Down  the  Stack 

Stealth  &  System  Control  I  ncrease 


Apps 


Apps 


Apps  Apps 


Apps 


Service  Abstraction 

Middleware 

OS 


Traditional  target  for 
disabling  security  tools 


OS  can  harbor  'advanced 
persistent  threats'  for  a 
specific  target 


CPU 


sw 

Driver  sw 

SW 

Driver 

Driver 

MEM 

HW 

HW 

HW 

sw 

Driver 


HW 


Embedded  Firmware 
malware  is  beyond  the 
reach  of  current  tools 

Ultimate  threat  resides  in 
the  hardware  blocks 


Buses 
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Are  EDA  companies  Ultimately  Responsible 
for  Solving  the  Security  Problem? 


Traditional  verification  role 

—  Verifying  a  chip  does  what  it 
is  supposed  to  do 


Emerging  new  role 

—  Verifying  a  chip  does  nothing 
it  is  NOT  supposed  to  do 
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EDA  as  the  first  line  of  defense 


■  What  to  attack  first? 

1.  Problems  that  have  measurable  impact 

2.  Appear  to  be  solvable 

3.  Customers  are  willing  pay  for  solutions 


■  Side-channel  Attacks  -  solutions  exist 

—  Attempt  to  leak  out  keys  via  differential  power  analysis  (and  the  like) 

—  Current  targets  are  mainly  in  smart-card  and  set-top  box  areas 

■  Counterfeiting  -  problem  apparent,  no  solutions  yet 

—  Over-produced,  cloned  re-marked,  recycled  or  otherwise  unauthorized 
ICs  provided  by  uninformed  or  untrustworthy  suppliers  and  distributors 
for  economic  or  adversarial  reasons 

■  Hardware  Trojans  -  a  theoretical  threat? 

—  Malicious  circuits  put  inside  a  chip  which  are  harmless  in  normal 
operation  until  triggered  by  a  preset  internal  or  external  condition(s) 
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CHARACTERI  Zl  NG 
THREAT  VECTORS 


But  it's  not  just  design,  the  whole  supply  chain  has  evolved: 

Evolution  of  I C  supply  chain  (past) 


IP  Tools  Std  Cells  Models 

i _ i  _ i _ i 

▼ 


Specifications  - Design  - Fab  Interface  - Mask  - ►  Fab 


I -  Wafers 

v 


Wafer  _ ^  Dice  and  _ ^  Package  _ ^  Deploy  and 

Probe  Package  Test  Monitor 

Level  of  Control  of  1C  Supply  Process 


Trusted 
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Graphics 


Evolution  of  I C  supply  chain  (present) 


IP  Tools  Std  Cells  Models 

i _ i _ _ i _ i 

T 

Specifications  — ►  Design  - ►  Fab  Interface  — ►  Mask  - ►  Fab 


Wafers 


t 


Wafer 

- ► 

Dice  and 

Package 

_ ^  Deploy  and 

Probe 

Package 

Test 

Monitor 

Level  of  Control  of  1C  Supply  Process 


Trusted  Untrusted  Either 


GrapliKS 
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Attacking  I C  design  flow 
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Manufacturing  stages  many  attack  vectors 


-200  processing  steps  in  1C  fabrication 


Lithography  processes 
present  opportunities  to 
print  additional  circuitry 
and  devices 


Need  to  replace  glass 
masks 

Masks  are  automatically 
loaded  into  litho  tools 
No  physical  access  to 
target  tool  required 


Other  process  and 
measurement/metrology 
steps  present  opportunities 
for  causing  scraps 


Silicon 

Wafer 


Manufacturing  Line 


Trojan  circuitry  may  be 
inserted  in  different  layers 
of  circuitry  within  the  chip 


w* 


Long  manufacturing  lines 
-200  processing  steps 

Many  opportunities  for 
malicious  insiders 


Targeting  processes  at 
the  BEOL  (Back  End  Of 
the  Line)  causes  higher 
damages  to  the  1C 
manufacturer. 
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COUNTERFEITING 


Over-produced,  cloned  re-marked,  recycled  or  otherwise  unauthorized  ICs  provided  by 
uninformed  or  untrustworthy  suppliers  and  distributors  for  economic  or  adversarial  reasons 


Electronics  Supply  Chain  is  Global 

Global  nature  of  supply  chain  makes  chain=of=custgdym  approach  unworkable 


Philipp*« 


Stfigapors 


McjoCP 


Cons  Rica 


Semi  Design 


Semi  Manufacturing  & 
Packaging 


Printed  Circuit  ■  Printed  Circuit  Board 
Board  Production  I  Distribution 


Lifecycle  for  a  single  JSF  (Joint  Strike  Fighter)  1C 
-  Component  changed  hands  15  times  before  final  install 


—Mentor 

Graphics 
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Source:  I  DC  Manufacturing  Insights  &  Booz  Allen  analysis 
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How  can  we  build  trusted  silicon  in  an  untrusted 
environment?  VPN  for  I  Cs? 
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Authentication  alone  is  not  enough: 

Additional  mechanisms  to  be  considered  for  higher  security  levels 


■  A  more  comprehensive  EDA  tool  is  needed 


On-chip  odometers  can  address  recycling  threat 

—  On  chip  structures  that  count  some  physical  events  like  power  cycles, 
memory  accesses  or  other  inexpensively  measurable  values 

—  Data  in  the  odometer  is  encrypted;  reset  to  '0'  indicates  an  attack 

—  Can  be  accessed  at  the  authentication  time 


Activation  -  chips  do  not  work  as  manufactured 

—  Only  the  I P  rights  holder  would  have  the  keys  needed  to  activate  chips 

—  Different  degrees  of  activation  need  to  be  offered  to  enable  the 
customer  to  make  trade-offs  between  security  and  costs 

—  Pre-existing  test  methods  should  be  accommodated 

—  Power-up,  event- based  or  periodic  activation  offers  highest  security 
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Chip  Activation  by  Logic  Encryption 


I  nject  "security  gates"  into  the  design 
Security  gates  are  no-ops  if  the  key  value  is  correct 
Security  gates  break  functionality  if  the  key  value  is  wrong 
At  least  one  gate  per  key  bit 


—  More  gates  (up  to  a  point)  can  be  used  to roDU|Dje'J<eyjDjts  and 
increase  variance  of  the  outputs 


Key  strength  increases  with  key  register 


size 
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Managing  Keys  Securely 


Design  house  may  never  see  the 
actual  keys  if  they  are  managed 
by  PaaS  (Platform  as  a  Service) 
technology 

A  secure  key  management 
platform  could  be  operated  by 

—  Government  agency  (ex:  DoD) 

—  Commercial  entity  (ex:  Amazon) 

—  The  Design  House's  own  cloud 


PaaS  would  expose  a  Web 
Services  API  that  all  EDA  tools  in 
the  chain  would  access  to  deposit 
or  access  key  via  encrypted 
communications 


Logic  Encryption  EDA  Tools 


^  Create  the  environment 

0  UrtiK  ttrc  cnYirgnmtrn 

^  C/eatc  the  application 

^  Update  th«  application 

^  Deploy  the  application 

^  Start  the  application 

^  Stop  the  application 

^Un-deploy  the  application 

^  Delete  the  application 


<5  S 
*  < 


Key  Management  Backend 
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Different  types  of  solution  are  needed 


Offline  authentication 


—  Valid  chip  contain  a  unique  key  that  can  be  verified  offline 

—  Unauthorized  chips  work  but  can  be  identified  (if  in  possession) 


One-time  activation  using  globa[key 

—  As- manufactured  chips  do  not  work 

—  Key  needs  to  be  entered  to  activate  the  chip 


One-time  activation  using  unique  key 


—  Same  as  above  but  key  is  unique  for  each  chip 


Power-up  activation  using  unique  key 


—  Chip  is  not  activated  permanently,  each  use  must  be  activated 
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cost 


Solution  Space  for  I P  Protection 


security 
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1C  price 


Markets  for  Supply  Chain  Security  Solutions 
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security 


Readout 

Technologies 


Needed:  scalable  platform  that  can  support 
multiple  contributions  from  many  parties 


Need  to  raise  the  bar  to 
deter  financial  incentive, 
can't  solve  Nation-State 
Attack 

New,  digital  design  is 
target  (not  discrete  or 
existing  design) 

Following  traditional  EDA 
methods,  crypto,  security 
gates,  registers  insertion, 
access  can  be  automated, 
verification  performed 

User  assisted  selection  of 
crypto,  activation  block, 

#  of  registers 

EDA  contribution: 
Standard  insertion 
methods  and  interface 
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TROJANS 


Malicious  circuits  put  inside  a  chip  which  are  harmless  in  normal  operation 
until  triggered  by  a  preset  internal  or  external  condition(s) 


Threat  Example:  Compromised  Router 


Management 
SNMP.  Telnet 


ICMP 


Coolrql  Plqnq 

ip  JHl  Routing  Management 

updaies  SSKSSL 


Carrier  of  a 
contaminated 
control 
message 


Control  Plana  Policing 

<|AJiavta]05  DoS  attach) 


Incoming  Packet 
Jacfceis  Buffer 


Input 

io  Control  Plane 


A 


Procassor 
Switched  Packet: 


<£:■ 


CEF/FIB  Lookup 


Output 

from  Conlrol  Piaoe 


Silent  Mode 

(F'mventi  reconnai&sa^cej 


Output  Packet 
Bufter 

Locally 

Switched  PacksiB  Ijgi 


■  Unpublished  control  message  travels  around  the  internet 
and  is  unrecognized  and  ignore  by  most  routers 

■  When  a  router  containing  a  hardware  Trojan  in  the  control 
plane  sees  such  message,  it  takes  action  to  re-direct  data 
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Why  is  Trojan  Detection  Difficult? 

■  Low  probability  of  triggering  during  test 

—  Even  a  small  1C  today  has  millions  of  nodes 
—  There  are  billions  of  states 
—  Tests  are  for  known  use  cases 
—  Test  time  is  expensive 

—  Consider  testing  a  million  chips  per  production  batch 
—  Very  difficult  to  test  for  Unknown  Unknowns 

■  Large  number  of  gates  in  modem  chips 

—  Exhaustive  simulations  are  extremely  computation  and  memory  intensive 
—  Obfuscation  occurs  during  synthesis 

—  No  signature  in  Trojan  circuits  -  they  look  just  like  normal  hardware 

—  Low  probability  triggers  are  finite  state  machines  that  can  change  states 
when  time  or  input  data  changes 

—  Nano-scale  devices  and  high  system  complexity  make  detection  through 
physical  inspection  almost  impossible 
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IP  as  a  Trojan  carrier 


In  a  typical  IP-based  design,  each  block 
can  originate  from  different  sources 

I  ncoming  I P  blocks  are  verified  to  confirm 
promised  functionality 

Additional  verification  may  be  done  to 
confirm  proper  interaction  with  other  I P 
blocks  operating  in  the  system  context 


A  key  question  that  does  NOT  get  asked 
in  this  process  is:  “does  this  block  do 
anything  ELSE?" 

Possible  countermeasures: 

—  Scan  incoming  I P  for  Trojan  signatures  -  HARD 

—  I  nsert  run-time  detection  mechanisms 
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Possible  Trojan  Solution 


■  Design  time  detection  -  not  viable 

—  Expanded  test  benches 

—  Formal  methods 

■  Solution:  Run-time  Trojan  detection 

—  Using  declarative  form,  describe  rules 
governing  bus-based  communications 

—  Synthesize  bus- interface  logic  &  co¬ 
processor 

—  Generate  encrypted  microcode  containing 
detection  mechanisms  for  known  attack 
profile  as  well  as  system  architecture 
specific  ones 

—  I  nclude  co-processor  in  the  design 


CPU 


Memory 


Input  and 
Output 

t  i 


. I . ii . 

^  r 

- r  1 

Control  bus 

' 

r 

1  1_ J 

' 

Address  bus 

Data  bus 


l 


rules 


Cyber-Security 

Co-processor 
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® 

Semiconductor 
Research  Corporation 


Pioneers  in 
Collaborative 
Research® 


STARSS: 

Fundamental  Design-f or- Security  Research 


Dr.  Celia  Merzbacher 

VP  for  I  nnovative  Partnerships  &  Government  Relations 
Director,  Trustworthy  and  Secure  Semiconductors  and  Systems 
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I  just  want  to  say  one  word  to  you.  Just  one  word. 
Are  you  listening? 

Cybersecurity. 


Semiconductor  I  ndustry  T rends  & 
Challenges 


■  More  pervasive,  embedded,  and 
networked,  including  in  critical 
infrastructure  systems 

■  More  complex  (SoC,  NoC,  SoS) 

■  More  3rd  party  I P 

■  Supply  chain  more  global 

★  More  vulnerabilities 

★  Greater  impact  if  chip  fails 

★  More  attractive  to  adversaries 


Trustworthy  and  Secure  Semiconductors  and  Systems  (T3S): 

A  New  Thrust  in  the  SRC  Portfolio 


Global  Research 
Collaboration 

Ensuring  vitality  of 
current  industry 


SemiSynBio 


Advanced 

Connectivity 


W 

STARnet 


Focus  Center  Research  Program 
Phase  VI 

STARnet 

Early  research 
engagement  of  key 
long  horizon 
semiconductor 
challenges 


Nanoelectronics 

Research 

Initiative 

Beyond  CMOS  -the 
next  switch  and 
associated 
architectures 


S 

EducationAlliance"4 

tor  Sotnci,  A  Tech'oJojy 


Education 

Alliance 

Attracting  and 
educating  the 
next  generation 
of  innovators 
and  technology 
leaders 


Bringing  industry  together  to  identify  and  support  -  in  collaboration  with 
government  -  fundamental  research  for  hardware  assurance. 


Essential  Features  of  SRC  Programs 


Highly  leveraged  investment  in  research 

Needs-driven,  consensus- based  goals 

World-class  researchers  (faculty  &  students) 

I  nteraction  among  academic  and  industry  experts 

All  members  have  rights  to  resulting  I P 

Facilitated  tech  transfer  via  liaisons,  online  tools  for  access  to 
project  information,  student  resumes,  etc.;  webinars  and  in 
person  reviews 

Nimble  and  adaptable  (does  not  fund  "bricks  &  mortar") 
Accountable;  value-driven;  efficient;  effective 


Challenges  and  Add  Value  1 

■  Goal:  Provide  maximum  assurance  that  I  P/chips/  systems 
will  perform  only  as  intended  without  impacting  time  to 
market,  cost  &  performance  and  are  resistant  to  attack/theft 

■  Objectives: 

•  Develop  cost-effective  strategies,  techniques  and  tools  to 
increase  security,  trust,  and  assurance  in  chip-based 
components  and  systems 

•  Form  public- private  partnerships  that  leverage  investment 

•  Grow/tap  into  the  university  research  enterprise 

■  I  nitial  participants 


freescale~ 


—Mentor 

Graphics* 


Step  1: 


Define  Research  Needs 


SRC-NSF  sponsored  workshop  in  J  anuary  2013*,  with  experts 
from  industry,  academia  and  government,  identified  the 
following  areas: 

■  Design  and  Manufacture  for  Security  and  Assurance,  including  properties, 
principles,  architecture,  specification,  verification  (internal  and  3rd  party 

I P)  and  validation 

■  Metrics  for  evaluating  security  and  trustworthiness 

■  Vulnerability  and  threat  assessment  and  frameworks 

■  Anti-counterfeiting  strategies/techniques,  e.g., 
authentication  of  semiconductor  provenance 
tamper  resistance,  and  securing  the  supply  chain 


m  i-  & 

trm-stujopstmu, 

5EMI  COt^OUCrroRS 


*  Research  needs  report  available  at  http:/  /  www.src.org/  calendar/  e004965/ 
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Survey  of  Hardware  Security  Threats 


■  Via  email  in  May  2014 

■  Sent  to  —200  individuals  in  industry,  academia  and 
government;  received  60  responses 

■  Summary  available  via  the  SRC  website  at 

f  i  le:  IIIO.  /  Users/  merzbacher/  Downloads/  starss- 

survev-results.  pdf 
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Q1  What  are  the  top  three  current  threats. 

Q2  What  will  be  the  top  three  threats  in  10-20  years. 


Other 

Emerging  tech  vuln. 
Tamper/Trojan 
Fake  current  parts 
Fake  legacy  parts 


Other  Threats 


Reverse  engineering 

Hardware  features  that  enable  software  and  data 
attack 

The  primary  challenge  in  10  -  20  years  will  likely 
be  something  we  are  not  aware  of  today. 


Current  Threat  Ranking  by  Sector 


■  Govt  BAcad  Hind 


Future  Threat  Ranking  by  Sector 

- Jim - ★ - 

ll  |  ★ 


■  Govt  BAcad  Hind 


Q3:  Rank  the  following  threat  agents  in  order  of  concern  to 
you/your  organization  today. 

Insider  . . -""“t1 

Competitor 

Econ  attack  I  I 

Political  attack 


Hacker 


Threat  Agent  Ranking  by  Sector 


■  Govt  ■  Acad  ■  Ind 


Q4:  What  are  the  top  three  research  challenges  that  you 
feel  can  and  should  be  addressed  by  university  research  in 
the  next  3-5  years? 


Other 

SC  assur/provenance 
HW/SW  co-design 
loT,  distrib  nets 
Sec.  composition 
Est.  assurance 
Roots  of  Trust 
Run-time  monitor 
Threat  assess. 
Metrics 
Features  (e.g.  PUFs) 
Verification 
Design 


Other  Research  Needs 


Design  for  resilience  against  security  attacks 
(similar  to  fault  tolerance  against  operational 
defects) 

Role  of  humans  in  building  and  operating 
assured  systems 


Research  Needs  Ranking  by  Sector 


■  Govt  BAcad  mind 
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T3S  Status 


•  Engaging/  recruiting  additional  members  &  partners 

I  n  discussion  with  other  semiconductor  companies;  network  &  other 
system  developers/ integrators;  and  critical  infrastructure  companies 

Workshop  held  in  May  2014 — 31  companies  participated — to  discuss 
drivers,  capabilities,  gaps  and  research  needs. 

https:  //www.  src.  orq/  calendar/  e005440/ 

Engaging  additional  government  partners  with  interests/ investments  in 
university  research  and  education 

•  National  Science  Foundation  (NSF)  and  T3S  co- funding  a  multi¬ 
million  program  on  Secure,  Trustworthy,  Assured,  and  Resilient 
Semiconductors  and  Systems  (STARSS). 

First  round  of  projects  have  been  selected  and  will  start  in  Q4  2014 


18 


NSF-T3S  STARSS  Solicitation  Topics 


Architecture  &  Design:  Architectural  and  design  approaches,  models,  and 
frameworks  for  reasoning  about  and  specifying  hardware- specific  security 
properties 

Properties,  Principles  &  Metrics:  Development  of  a  set  of  hardware 
security  design  principles  and  semiconductor-specific  properties 

Security  Verification  &  Analysis:  Tools,  techniques,  and  methodologies  for 
verifying  hardware-specific  security  properties  and  enforcing  the  security 
design  principles 

Threat  Assessment:  Frameworks  for  analyzing  and  sharing  information 
about  security  threats  due  to  unintended  vulnerabilities  or  malicious  attack 
during  design  or  manufacture. 

Authentication  &  Attestation:  Models  for  the  insertion  of  artifacts  and/or 
design  elements  that  are  verifiable  during  design  and  manufacture. 

Tools  and  Frameworks:  Develop  security  engineering  models  for 
implementation  of  research  results  and  for  use  in  education  and  training  of 
engineers. 


More  details  at  http://www.  nsf.  go  v/ pubs/ 201 4/ ns fl 4528/ ns fl 4528.  htm 
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1st  Round  of  STARSS  Projects 


■  Secure  chip  odometers  for  measuring  use  and  age 

■  Trojan  detection  and  diagnosis 

■  PUF-based  authentication 

■  Design  of  low-cost  memory-based  security  primitives  and 
techniques 

■  Design  &  Metrics  for  resistance  to  differential  power 
analysis  attack 

■  Understanding  and  detection  of  fault-based  attacks 

■  I P  integrity  validation 

■  Hierarchical  approach  to  design  of  secure  IC's  using 
authentication  and  obfuscation 

■  I  nvariant  carrying  machine  for  hardware  assurance 
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Design  for  STAR 


Increasingly  recognized  as  important... 
But  remains  a  challenge. 


Google  Project  Ara  modular  phone 
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Appendix  C  -  Design  for  Security  Workshop  Outbrief 


USC  Viterbi 

School  of  Engineering 


Information  Sciences  institute 


Design  for  Security  Working  Meeting 

Final  Report 


J  eff  Draper 

Project  Leader,  I  nformation  Sciences  I  nstitute 
Research  Associate  Professor,  Ming  Hsieh  Department  of  EE 

I  SI ,  Marina  del  Rey,  CA 
September  29,  2014 


use  Viterbi 

School  of  Engineering 


Sponsorship 

Acknowledgment 


ISI 

Information  Sciences  Institute 


•  U.  S.  Army  Research  Office  Award  No.  W911NF- 13- 1-0261 
POC:  Dr.  Cliff  Wang 


•  The  views,  opinions,  and/or  findings  contained  in  this  report  are  those  of  the 
author(s)  and  should  not  be  construed  as  an  official  Department  of  the  Army 
position,  policy,  or  decision,  unless  so  designated  by  other  documentation. 


use 
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use  Viterbi 

School  of  Engineering 


Design  for  Security 


ISI 

Information  Sciences  Institute 


—  Motivation 

■  Protection  of  / nteiiectuai  Property  (IP),  critical  components  of  all 
DoD  designs 

-  Additionally,  DoD  has  a  legacy  / P  protection  issue 

»  Designs  spanning  the  last  30  years  with  thousands  of  different  IP 
blocks 

-  intersection  of  security,  reliability,  safety 

-  Mission  sustaining  capability 

»  i hfrastructure  for  combatting  unknown  unknowns 

—  I P  Protection 

■  Privacy 

■  Copying/counterfeiting 

■  Sabotage 

—  Challenges  (  Areas  needing  investment) 

■  Metrics  for  quantifying  design  security 

■  Tools  for  measuring  design  security  and  developing/evaluating 
mitigation  approaches 


use 


use  Viterbi 

#c I 

School  of  Engineering 

Motivation 

/m+rm 

Information  Sciences  Institute 

•  Intellectual  Property  (IP)  intensive  industries  account  for  20%  of 
the  US  workforce  and  a  third  of  GDP1 


•  Many  reported  IP  compromises  involve  chip-based  platforms2 


Figure  4.  Compromised  assets  by  percent  of  breaches  involving  Intellectual  Property  theft* 


Type 

Category 

Data  base  server 

Servers 

|43% 

File  server 

Servers 

|  32% 

Fin  an  ce/A  cco  unting  sta  f  f 

People 

|29% 

Human  resources  staff 

People 

Documents 

Offline  Data 

|2B% 

Regular  emp  Icy  ee/end -user 

People 

|28% 

Web/application  server 

Servers 

|  25% 

Mail  server 

Servers 

|  12% 

D  irectory  s  erver  ( L  DAP,  A  D ) 

Servers 

|  £% 

Executive/Upper  Management 

People 

|  e% 

Desktop/Workstation 

User  Devices 

|  5% 

invoked  in  less  than  ISti  of  bf  eaches  are  not  shewn 


Trusted  chips  are 
crucial  to  improve 
the  security  of 
servers  and 
devices 


For  DoD,  chips  are 
core  to  modern  weapon 
systems,  including 
airplane,  missile, 
C4ISR,  etc. 
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use  Viterbi 

#c I 
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Motivation 

/m+rm 

Information  Sciences  Institute 

•  Chip-level  IP  protection  strategies  must  consider  various  threats 


—  Privacy 

■  Preventing  reverse  engineering 

—  Theft 

■  Copying  /  counterfeiting 

—  Sabotage 

■  Preventing  denial  of  service  or  more  insidious  attacks 

—  Relationships  between  threats 

■  Threats  are  not  necessarily  mutually  exclusive  or  hierarchical,  i.e.,  copying  can  be  done 
without  any  knowledge  of  how  a  design  really  works 

•  DoD  IP  protection  involves  critical  factors  that  are  not  as  dominant  in 
consumer  market  and  therefore  not  likely  to  be  addressed  by  commercial 
ventures  alone 
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Legacy  IP  protection 

■  Theory/tools  needed  for  assessing  vulnerabilities  in  legacy  systems 

Mission-sustaining  capability 

■  Approaches  must  consider  long  deployment  lifetimes 

Information  dominance 

■  DoD ’s  C4ISR  must  be  protected  and  trusted 
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Scope  of  Problem 
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•  All  facets  of  IC  industry  have  a  stake  in  the  game,  for 
example 
—  ARM 


■  Embedded  core  ecosystem  where  customer  demands  protection 

■  Trustzone  approach  only  beginning  to  tackle  the  problem 

—  Xilinx 

■  FPGA  protection,  especially  configuration  scan  chain 

■  Zynq  secure  boot  addresses  only  part  of  the  problem 

—  Mentor 

■  Trustworthy  CAD  tool  flow  for  generating/verifying  chip  designs 

•  Will  markets  really  be  willing  to  pay  the  cost  for  added 
_ protection  ? 
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Challenges 
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•  Developing  a  holistic  approach  that  enables  security  to  be 
quantified  so  that  it  can  be  treated  as  a  design  constraint 

—  If  successful,  should  be  able  to  easily  extend  current  design 
flow  using  security  as  another  constraint  (similar  to  area, 
energy,  speed)  in  multi-objective  optimizations 

—  Implies  development  of  an  “algebra”  for  quantifiable 
assessments 


•  Reducing  such  a  paradigm  to  practice 
—  Techniques 
—  Tools 


Indirect  effect  on  other  parts  of  chip  design  flow,  like  testing 

■  Must  incorporate  intelligent  targeted  testing  accounting  for  attack  types;  Monte 
Carlo-style  testing  alone  will  not  suffice 
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Information  Sciences  Institute 

•  Success  of  an  extensive  design  for  security  approach 
hinges  on  quantifiable  measures  of  security,  or  metrics 

•  Prior  work  in  this  area  has  been  largely  theoretical 
without  a  means  to  reduce  to  practice 

•  Potential  tiered  approach  may  enable  traction 

—  Capture  design  statistics  at  various  levels  that  could  contribute 
to  a  measure  of  security 

■  e.g.,  layer  density  at  layout  level,  complete  state  machine  transition  specification  at  RTL 
level,  complexity  figures  (number  of  gates,  number  of  nets,  fanout  averages,  etc) 

—  Combine  design  statistics  with  attack-specific  information 

■  While  design  statistics  are  static  with  respect  to  a  specific  design,  the  contribution  of  the 
attack- specific  information  to  a  security  measure  is  dynamic,  changing  with  the  added 
knowledge  of  future  attack  types 
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Mul it-  Level  Security 
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Metrics 
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•  Different  levels  of  views  of  security  and  associated  metrics  (from  each 
specific  attack  to  general  resilience  issues  against  the  unknown 
unknowns) 


•  Establish  composite  security  metrics 

•  Account  for: 

—  Dynamic  risk/reward  model 
—  Cost  to  implement 
—  Cost  to  detect 
—  Cost  of  attack 

—  Attribution  of  attack  (designer,  foundry,  etc) 

—  Impact  of  attack 

—  Resilience  to  attacks 

■  Side  channel  exposure,  reversability 

•  Approach  should  not  be  dominated  by  any  specific  problem/attack  and 
should  envision  the  presence  of  future  unknown  unknowns 
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Sensitivity  Study 
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•  Metrics  and  tools  for  design  security  must  consider 
nuances  of  targeted  domains 
—  Analog  /  mixed-signal 
—  Digital 

■  Control  blocks  versus  datapath  structures 

■  Pipelined  structures 

■  State  machine  structures 


•  Must  consider  each  level  of  design  flow  and  identify 
overlapping,  orthogonal,  or  even  conflicting  issues 
between  various  levels  of  design 
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Top  5  Research  Area 
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Priorities 

Information  Sciences  Institute 

•  Overarching  theme:  need  for  systematic  approach  to 
HW  security 


Methods  to  create  verifiably  secure,  attack-resistant  IP  at  all 
levels  of  design  hierarchy,  including  definitions  of  metrics 

■  Methodologies/techniques  for  the  behavioral  modeling  of  the 
security  of  devices  and  systems 

Tools  for  secure  interplay  between  hardware  and  software 

Design  environment  for  modeling  and  simulating  hardware 
attacks  and  actions  for  mitigation 

■  Extensions  to  HW  description  languages  that  capture  security 
attributes 
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